Recommend PKCE and deprecate the client secret - #974

…optional

Trakt deprecated the client secret on 2026-10-01 (trakt/trakt-api#974): apps
created since then are PKCE-only and have no secret, and `client_secret` is
now optional/deprecated on every /oauth body. The device flow still works for
these apps — you just omit `client_secret` (the device_code is the proof of
possession). PKCE itself isn't used by the device flow; it only exists in the
authorization-code flow.

Without this, a PKCE-only Client ID can't connect: isConfigured() required a
secret and the token/refresh/revoke calls always sent one, which Trakt rejects.

- client_secret is now optional on device/token, token refresh, and revoke
  (sent only when the app still has one, so legacy apps keep working).
- isConfigured() requires only a Client ID.
- OAuth requests target auth.trakt.tv per current Trakt docs; the data API
  stays on api.trakt.tv.
- Settings: the Client Secret field is marked optional and no longer gates
  "Connect".

Adds TraktPkceAuthTests covering the secret-less device-token/refresh request
bodies, legacy-secret backward-compat, isConfigured, and the OAuth host.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

<!-- claude-projects-attribution: {"github_login":"bendrucker"} -->
_Requested by **Ben** · [project
thread](https://claude.ai/code/project/chan_01TWyQ8yB7mqhkPt3YqS4rif?thread=cmsg_01TWyQ8yB7mqhkPt3YqS4rif5Weg2UHc3iexFshwczPTxF)_

Before: the pipeline and the monitor read Trakt with only the client ID.
The first request of many hours drew a 429 with a `Retry-After` of up to
260s, even though the hub sends only two or three requests an hour.
After a 429, history and ratings stopped until the next hour, and the
monitor's Trakt probe failed.

After: both read Trakt as the account through OAuth, each with its own
Trakt application and grant. Trakt has no personal access token, so each
one links once through Trakt's device flow. Until a grant is stored, the
pipeline records `skip.missing_secret` for both Trakt kinds and the
nightly re-walk, and the monitor leaves Trakt out of its probe. Neither
Worker uses a client secret. Trakt deprecated them in favor of PKCE
([trakt-api#974](trakt/trakt-api#974)), and the
device and refresh calls send the client ID alone.

How, pipeline: `src/trakt/auth.ts` resolves the token once per
invocation from D1's `trakt_tokens`. It refreshes once six hours or less
remain on Trakt's 24-hour token. The grant lives in D1 rather than KV
because Trakt rotates the refresh token on every refresh, and an
eventually consistent read of a rotated token would be a dead
credential. Rotation drives the rest of the design:

- A refresh writes only over the row it read. If Trakt refuses a refresh
token that a concurrent invocation already spent (`invalid_grant`), the
losing invocation re-reads the row, immediately and again two seconds
later, to pick up the winner's token.
- Any refusal or failure before Trakt issues a grant falls back to the
token in hand while it has time left. Once that token lapses, the error
says what to fix. `invalid_grant` means re-run the login. Any other
refusal means the client ID and redirect URI don't match the Trakt
application.
- Once Trakt issues a grant, the old refresh token is spent. The D1
write retries. If it still fails, the invocation keeps the new token
rather than dropping it.
- A 429 from the token endpoint is a rate-limit stop with `resumeAt`.
Token endpoint failures carry `endpoint: "oauth"`, which keeps their
bodies out of R2, where only data pages are archived.

The device-flow routes are `POST /admin/trakt/login`, and
`/admin/trakt/login/poll` with `device_code` in a JSON body. They
exchange the code inside the Worker, so the grant never leaves it, and
the code never appears in a URL. Without a client secret, the code plus
the public client ID is enough to claim the grant. A refresh repeats
`TRAKT_REDIRECT_URI` (`https://bendrucker.me/`), which must be
registered on the app. A 429's message now names the limit from
`X-Ratelimit`, or says the header was missing.

How, monitor: `workers/monitor/src/trakt-auth.ts` is a trimmed copy of
the refresh logic with the same fallback and write retry. It has no
concurrency guard, since the monitor runs once an hour on its own. The
token resolves once per run, on first use. A D1 failure reading the
grant leaves Trakt out of the probe rather than failing the run. The
monitor has no admin surface, so `bun run monitor:trakt-login` runs the
device flow locally with the monitor's client ID. It writes the grant to
the monitor's D1 through a temporary file passed to `wrangler d1 execute
--remote`.

Setup after merge:

1. Register `https://bendrucker.me/` as a redirect URI on both Trakt
apps and remove `urn:ietf:wg:oauth:2.0:oob`.
2. Link each app:

```sh
ADMIN_TOKEN=... bun run trakt:login https://<worker-host>
bun run monitor:trakt-login
```

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01PjhteXVmB2DedotVunbH21

---------

Co-authored-by: Claude <noreply@anthropic.com>

…hed and bring in your watchlist

Signing in is Trakt's device code with PKCE: only the Client ID is needed, since Trakt no longer issues a client
secret to new apps (trakt/trakt-api#974). A secret from an older app is still sent.
Titles from Trakt show only when one of the TV's apps has them, like TMDB's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…hed and bring in your watchlist

Signing in is Trakt's device code with PKCE: only the Client ID is needed, since Trakt no longer issues a client
secret to new apps (trakt/trakt-api#974). A secret from an older app is still sent.
Titles from Trakt show only when one of the TV's apps has them, like TMDB's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>